atomic multipath payments (AMP)

2021-12-14 · 3 min read

#lightning

TODO: can apparently use AMP for non-interactive payments?

1-share AMP = spontaneous payment

Setup #

Alice has two payment channels open with Bob (or some path to Bob), each with outbound capacity of 1 BTC. Alice wants to pay Bob 2 BTC.

flowchart LR;
	A[Alice] -->|1:0| B;
	A[Alice] -->|1:0| B;

	B[Bob];

Problem #

Naively, Alice could pay Bob in two separate payments:

Payment 1:

flowchart LR;
	A[Alice] -->|0:1| B;
	A[Alice] -->|1:0| B;

	B[Bob];

Payment 2:

flowchart LR;
	A[Alice] -->|0:1| B;
	A[Alice] -->|0:1| B;

	B[Bob];

However, if the second payment fails, the total 2 BTC payment is only paritally fulfilled and Alice has no way of getting the initial 1 BTC back without trust/coordination.

Solution #

Atomic Multipath Payments let you split a payment to a recipient and send each piece over completely separate routes, yet the recipient can only fully receive the payment if all pieces complete successfully.

Desired Properties: + Atomicity: Bob doesn't receive any money until all pieces of the payment come through. + Avoid Payment Hash Reuse: Each payment piece has a distinct payment hash. (Why is this useful?) + Order Invariance: The payment pieces can fulfill in any order. + Non-interactive Setup: Bob doesn't have to know the transaction is an AMP.

Protocol Sketch #

let ID = random value to identify the overall AMP let V = total payment value let n = # payments/routes let v_1, .., v_n = V partitioned n ways, (exact values not important here)

Alice needs to generate a base preimage (BP) to encumber the overall payment. When Bob eventually learns BP, the payment should be 100% complete.

To construct BP, Alice samples n partial shares s_1, .., s_n. BP is then the sum of all partial shares, BP = s_1 ^ .. ^ s_n.

Alice then needs to construct n partial payments. For each payment, Alice constructs a partial payment preimage r_i = H(BP || i), which encumbers the i'th payment. The public partial payment hash h_i = H(r_i).

Alice then initiates each partial payment by constructing a route to the destination with value v_i and payment hash h_i. Alice also includes some info (ID, n, s_i) to identify the overall AMP and this partial payment's additive share.

Finally, when Bob receives all n payments, he can reconstruct BP = s_1 ^ .. ^ s_n. With BP, Bob can then reconstruct each partial payment preimage, which competes the total payment.